Conversation
sejoon00
reviewed
Mar 22, 2025
Contributor
sejoon00
left a comment
sejoon00
left a comment
There was a problem hiding this comment.
고생했어요!
JPA의 영속성 컨텍스트 저장 매커니즘을 한번 살펴보면 좋을 것 같아요
| public ProblemSetGetResponse getProblemSet(Long problemSetId) { | ||
| ProblemSet problemSet = problemSetRepository.findByIdElseThrow(problemSetId); | ||
| if (problemSet.isDeleted()) { | ||
| throw new BusinessException(ErrorCode.DELETE_PROBLEM_SET_GET_ERROR); |
Contributor
There was a problem hiding this comment.
명시적인 예외 클래스로 만들어주실 수 있을까요?
DeletedException 이라던지
|
|
||
| // 문항 및 새끼 문항의 개념 태그 조회 | ||
| List<Long> allProblemIds = problemSet.getProblemIds(); // 문제 ID 목록 | ||
| List<Long> childProblemIds = queryFactory |
Contributor
There was a problem hiding this comment.
위에서 problem과 childproblem을 fetch join해와서 한번더 조회를 하지않아도 될것 같아요
| problem.title.title, | ||
| problem.memo, | ||
| problem.mainProblemImageUrl | ||
| ) |
Contributor
There was a problem hiding this comment.
JPA는 select 문에 조회하고 싶은 엔티티를 넣어야지 영속성 컨텍스트에 반영해요
fetch join을 해서 영속성 컨텍스트에 넣어주거나 select 문에 엔티티를 선언해주어야해요
| .fetch(); | ||
|
|
||
| Set<Long> allProblemAndChildProblemIds = new HashSet<>(allProblemIds); | ||
| allProblemAndChildProblemIds.addAll(childProblemIds); // 문제 + 자식 문제 ID 합침 |
Contributor
There was a problem hiding this comment.
문항과 새끼문항의 아이디를 set으로 합치는 이유는 어떤걸가요?
| .from(problem) | ||
| .leftJoin(conceptTag) | ||
| .on(conceptTag.id.in(problem.conceptTagIds)) | ||
| .where(problem.id.in(allProblemAndChildProblemIds)) // 문제 + 자식 문제 ID |
Contributor
There was a problem hiding this comment.
문항 테이블에서 새끼 문항 id로 검색하는것 같은데요?
| .memo(tuple.get(problem.memo)) | ||
| .mainProblemImageUrl(tuple.get(problem.mainProblemImageUrl)) | ||
| .tagNames(conceptTagMap.getOrDefault(tuple.get(problem.id), new HashSet<>())) // 태그 매핑 | ||
| .build() |
Contributor
There was a problem hiding this comment.
DTO에 대한 정보가 repository까지 내려오는거는 유지보수 관점에서 좋지 않은것 같아요
DTO가 바뀌면 repository까지 수정하러 내려와야할 것 같네요
mapper로직을 넣어주거나 DTO 자체를 repository가 모르게 구성하는건 어떨까요?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
💡 Issue
📄 Description
기존 쿼리
문항세트에 속한 문항들을 개별 조회
문항에 속한 개념태그들을 개별 조회
SELECT절에 엔티티가 포함되어, 불필요한 필드들도 조회
위와 같은 문제점들 때문에, 문항세트에 속한 문항의 개수와 문항에 속한 개념태그들의 수가 늘어남에 따라 쿼리의 개수도 배로 증가하는 구조였습니다.
개선된 쿼리
문항세트에 속한 문항ID들을 조회합니다.
조회한 문항ID들을 IN절로 문항 필드들을 조회합니다 (여기서 새끼문항과 join을 통해 새끼문항의 ID들도 가져옵니다).
새끼문항에 속한 개념태그ID들 + 조회한 문항에 속한 개념태그ID들을 IN절로 조회합니다.
SELECT절에 필요한 필드만 명시적으로 남겼습니다.
최종적으로 총 4번의 쿼리로 개선했습니다.
💬 To Reviewers